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® Verfahren zurn Kornprimiern von dynamischen Webseiten und eine Datenverarbeitungseinrichtung zur 
Durchfuhrung des Verfahrens 

® Zum Komprimieren von dynamischen Webseiten wird 
vorgeschlagen, die dynamischen Webseiten auf statische 
Blocke zu untersuchen und nur die statischen Blocke, 
nicht aber in jedem Fall auch die dynamischen Blocke zu 
komprimieren, es sei denn, die Belastung der CPU des 
Webservers erlaubt dies. Die statischen Blocke werden in 
komprimierter Form abgespeichert, so date beim erneu- 
ten Abrufen keine erneute Kompression, sondern ledig- 
lich ein Ersetzen der unkomprimierten durch die kompri- 
mierten statischen Blocke erfolgen mu(5. 



m 

CO 
CD 



BUNDESDRUCKEREI 02.03 103 170/164/1 



10 



DE 101 46 356 A 1 



Beschreibung 

[0001] Die Erfindung betrifft ein Verfahren zum Komprinileren von dynamischen Webseiten sowie eine Datenverar- 
beitungseinrichtung zur Durchfuhrung des Verfahrens. 
5 [0002] Dynamiscbe Webseiten bestehen aus Inbalten, die zum Tfeil standig aktualisiert bzw. auf einen Nutzer angepaBt 
werden. Eine standige Aktualisierung erfolgt beispielsweise bei Webseiten, welche Borsenkurse wiedergeben. Eine auf 
den Nutzer angepaBte Anderung erfolgt beispielsweise bei Webseiten im I>Conrmerce-Bereich. 

[0003] Derartige dynamische Webseiten konnen als Tbmplate also als Schablonen oder lediglicb als Beschreibung von 
Aufbau und Inhalt der Webseite auf dem Webserver abgelegt sein, 

10 [0004] 1st eine Webseite als Template abgelegt, ist dessen Struktur vorgegeben. Eine solche Webseite kann daher ent- 
sprechend ihres Inhalts in statische und dynaniische Blocke unterteilt werden. Der Inhalt der dynamischen Blocke ist 
durch eine Abfolge von Befehlen in einer Programmier-, eine Skript- oder auch einer Kornmandosprache beschrieben, 
[0005] Bei einem Abruf der Seite durch einen Nutzer ersetzt der Application-Server die Beschreibung durch die aktu- 
ellen Inhalte, Aussehen und Aufbau bleiben bei einer aus einem Tbmplate generierten Webseite unverandert, wie dies in 

15 Fig. 1 gezeigt ist. 

[0006] Statische Blocke enthalten Inhalte, die nie oder in sehr groBen Zeitabstanden generiert werden. Diese Blocke 
sind oft in HTML geschrieben. 

[0007] Die Inhalte dynamischer Blocke werden in kurzen Zeitabstanden, z, B, bei jedem Abruf der Webseite, generiert. 
Die Inhalte sind zunachst nur beschrieben. Erst beim Generieren wird diese Beschreibung dann durch Daten ersetzt. 
20 [0008] Die Beschreibung kann durch eine Programmier-, eine Skript- oder auch eine Kornmandosprache erfolgen. Ge- 
wohnlich werden Skriptsprachen verwendet, da diese sich gut in HTML integrieren lassen. Beispiele fur Skriptsprachen 
sind: 

- PHP (abgeleitet aus Hypertext Preprocessor) als eine offene serverseitige Skriptsprache, die jeder frei nutzen und 
25 andern kann oder 

- JSP (Java Server Pages) 

[0009] Der Nutzer ruft mit dem Eingeben und Bestatigen einer URL-Adresse im Browser eine Webseite auf. Das be- 
deutet, der Browser sendet an den Webserver ein Request (Anfrage), Dieser Request enthalt neben der URL der ge- 
30 wunschten Webseite eine Fulle von Informadonen iiber die Fahigkeiten des Browsers, z, B. iiber die unterstutzten Kom- 
pressions verfahren, MEME-Typen oder den Browser Typ. Der Webserver wertet den Request aus und versucht, die zu 
ubertragenen Daten an den Browser anzupassen. 

[0010] Statische Webseiten sind in der Regel auf dem Webserver in komprimierter Form (GZip- und Compress-For- 
mat) abgelegt. GZip und Compress sind die gangigen Kompressions verfahren fur statische "V\febseiten. Entsprechend den 

35 Fahigkeiten des Browsers wird die Webseite im GZip- oder Compress-Format ubertragen. 

[0011] Unterstutzt der Browser kein Kompressionsverfahren, ubertragt der Webserver die Webseite unkomprimiert. 
[0012] Die Anfrage zu einer dynamischen Webseite reicht der Webserver zum Application-Server weiter, Dieser iiber- 
nimmt das Generieren der dynamische Blocke. Das heiBt, er ersetzt die beschriebenen dynamischen Blocke durch deren 
Inhalt. Die statischen Blocke der Webseite werden unkomprimiert eingefugt. Der Application-Server ubergibt die voll- 

ao standige dynamische Webseite dem Webserver. Dort kann eine Komprimierung erfolgen. Am Ende sendet der Webserver 
die Webseite zum Browser, wie dies Fig, 2 zeigt, 

[0013] Der Umfang und die Bedeutung dynamischer Webseiten im Internet nimmt aufgrund der vielfaltigen Einsatz- 
moglichkeiten standig zu. Beispiele sind dynamische Webseiten, die aktuelle Aktienwerte bereitstellen oder bei denen 
Wetterinformationen abgerufen werden konnen. 
45 [0014] Dynamische Webseiten stellen aber an die Webserver bedingt durch ihre Eigenschaften groBere Anforderun- 
gen. Die Schwierigkeit besteht im Bereitstellen komprimierter dynamischer Webseiten unter Beriicksichtigung der EfH- 
zienz des Webservers. 

[0015] Zwei wichtige GroBen fur die Effizienz eines Webservers sind die Verkehrslast und die CPU-Belastung. Ziel ist, 
daB beide GroBen in einem ausgewogenen Verhaltnis zueinander stehen und das stets eine Reserve fur auftretende Spit- 
50 zen verfugbar ist. 

[0016] Das Problem bei dynamischen Webseiten ist, daB sie sich nicht wie statische Webseiten vorkomprimieren und 
auf dem Webserver ablegen lassen. Damit konnen sie auf die zwei GroBen entscheidenden EinfluB haben. Folgende Si- 
tuationen sind moglich: 

Die dynamischen Webseiten werden nicht komprirniert und erhohen damit aufgrund des groBeren Datenumfangs massiv 
55 die Verkehrslast des Webservers. 

[0017] Die dynamischen Webseiten werden erst unmittelbar nach deren Generierung mit einem bestehendem Verfah- 
ren komprirniert. Der Nachteil ist eine hohe CPU-Belastung des Webservers, 
[0018] Das Diagramm gemaB Fig, 3 verdeutlicht die Problematik: 

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Komprimieren von dynamischen Webseiten sowie eine 
60 Daten verarbeitungsvorrichtung fur diesen Zweck vorzuschlagen, mittels derer in einfacher Vfeise eine Kompression bei 
verbesserter Ausnutzung des Ressourcenverbrauchs sichergestellt wird. 

[0019] Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine Datenverarbeitungseinrichtung nach An- 
spruch 21 gelost. 

[0020] In der nachfolgenden Beschreibung wird das erfindungsgemaBe Verfahren als "SSC" (Server Side Compres- 
65 sion) bezeichnet. 

[0021] Ein wesentlicher Punkt der Erfindung liegt darin, daB nicht "blind" komprirniert wird, sondem daB nur diejeni- 
gen Daten komprirniert werden, welche einen wesentlichen Anteil der gesamten zu ubertragenden Datenmenge bilden 
und die andererseits mit verringertem Aufwand komprimierbar sind. Die statischen Daten werden namlich nur bei einem 
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"Neuaufbau" einer Webseite geandert, bleiben also iiber lange Zeit unverandert erhalten. Die konnen damtn in kompri- 
mierter Form abgespeichert und immer wieder verwendet werden, 

[0022] Die Erfindung wird nachfolgend unter Bezugnahme auf die Abbidungen naher beschrieben. Hierbei zeigen: 
[0023] Fig, 1 einen Seitenabrufvorgang; 

[0024] Fig, 2 einen herkornmlichen Aufbau der Hardware; 5 

[0025] Fig. 3 ein Diagramm zur Hardwarebelastung bei herkornmlichen Techniken; 

[0026] Fig. 4 ein Diagramm zur Hardwarebelastung beim erfindungsgemafien Verfahren; 

[0027] Fig, 5 einen herkornmlichen Dalenflufi; 

[0028] Fig, 6 einen Datenflufi beim erfindungsgemaBen Verfahren; 

[0029] Fig, 7 einzelne Schritte beim Entstehen eines SSC-Dokuments; 10 
[0030] Fig, 8 einen Tag-Einfugevorgang; 
[0031] Fig, 9 den Aufbau einer Block-Datei; 
[0032] Fig, 10 einen 1. Kompressionsvorgang; 
[0033] Fig, 11 einen 2. Kompressionsvorgang; 

[0034] Fig. 12 ein SSC-Dokument und 15 
[0035] Fig. 1 3 einen schematischen Aufbau einer Datenverarbeitungseinrichtung gemaB der Erfindung. 
[0036] Eine Analyse dynamischer Webseiten in bezug auf die Zusamtnensetzung der Daten erbrachte folgendes Ergeb- 
nis: Der Anteil dynamischer Daten im Verhaltnis zu den statischen ist wesentlich geringer, Werden von einer dynami- 
schen Webseite also lediglich die statischen Daten komprimiert und die dynamischen unkomprimiert tibertragen, ist 
keine wesentliche Verringerung des Komprimierungsfaktors gegeniiber einer Komprimierung der kompletten Webseite 20 
zu erwarten. 

[0037] Diesen Effekt nutzt SSC, Bei dem Verfahren wird auf eine bessere Komprimierung zugunsten einer geringeren 
CPU-Belastung verzichtet. Es ist ein Kompromiss zwischen den beiden oben beschriebenenMoglichkeiten. Das Ergeb- 
nis veranschauHcht das Diagramm gemaB Fig. 4: 

Das Verhaltnis von Verkehrslast und CPU-Belastung ist nahezu ausgeglichen, der Ressourcenverbrauch des Webservers 25 
ist gering, 

[0038] Insbesondere wird also mit der Erfindung ein Verfahren zum Komprimieren von dynamischen Webseiten auf- 
gezeigt, insbesondere zum Komprimieren von Webseiten, die mindestens einen statischen Block und mindestens einen 
dynamischen, insbesondere durch Abruf von einem Nutzer veranderlichen Block aufweisen, die auf einem "v\fehserver 
und einem Application-Server vorgehalten oder generiert werden. Beim erfindungsgernaBen ^ferfahren werden nun fol- 30 
gende Schritte vorgenommen: 

Es wird ein Datensatz aufgenornmen, der mindestens einen statischen und einen dynamischen Block urnfaBt. 

[0039] Es wird jeweils eine Identitat aller im Datensatz vorhandenen statischen Blocke, also ein "Fingerprint" festge- 

stellt. 

[0040] Es wird festgestellt, ob statische Blocke mit derselben Identitat (mit demselben Fingerprint) in einem Block- 35 
speicher schon als komprimierte Blocke gespeichert sind. Wenn dies der Fall ist, so wird der im Datensatz vorhandene 
statische Block durch den entsprechenden komprimierten Block ersetzt. Wenn dies nicht der Fall ist, so wird der statische 
Block komprimiert und im Blockspeicher als komprimierter Block abgelegt Der komprimierte Block ersetzt dann wie- 
der den im Datensatz vorhandenen statischen Block. 

[0041] Abschliefiend wird ein Sendedatensatz abgesendet, bei welchem die statischen Blocke durch komprimierte 40 
Blocke ersetzt sind, wobei der Sendedatensatz selbstverstandlich auch die dynamischen Blocke enthalt. 
[0042] Vorzugsweise wird die Identitat eines statischen Blocks anhand einer, aus ihm selbst gewonnenen Kennung 
festgestellt. Diese Kennung soli so sein, dai3 eine Verwechslung rrdt anderen statischen Blocken (Blocken anderen In- 
halts) unwahrscheinlich ist. Die aus der Identitat gewonnene Kennung wird jedem komprimierten Block zugehorig im 
Blockspeicher gespeichert und beim Feststellen der Identitat zum ^rgleich mit den Identitaten der statischen Blocke im 45 
Datensatz verwendet. Es werden also nicht die statischen Blocke selbst miteinander verglichen sondem - was eine we- 
sentliche Verringerung des Aufwandes bedeutet - lediglich ihre Kennungen. Es kann als Kennung eine Prufsumme uber 
den statischen Block, insbesondere eine CRC-32-Summe verwendet werden. 

[0043] CRC-32 (Cyclic Redundancy Check mit 32-Bit-Priifsumme) ist ein gebrauchliches mathematisches \ferfahren 
zum Errnitteln einer Prm^summe . Mit Hilfe dieser Prufsumme konnen Identitatsprufungen durchgefuhrt oder wie bei SS C 50 
Datenmengen verglichen werden. Der Vorteil dieses Verfahrens ist, daB eine geringe Abweichung bei den Daten eine 
groBe Anderung der Prufsumme bewirkt und damit auch kleinste Fehler nicht iibersehen werden konnen. 
[0044] Die Verkehrslast bestimmt die Datenmenge, die innerhalb eines Zeitintervalls vom Webserver abgefordert wird. 
Sie ist abhangig von der Anzahl der Requests (Anfragen zu Webseiten, die auf dem Webserver abgelegt sind) und von der 
Datenmenge, die als Antwort pro Request zum Client iibertragen wird. Wahrend eine hohe Anzahl an Requests er- 55 
wunscht ist, versucht man die zu iibertragende Datenmenge durch Kompressions verfahren moglichst gering zu halten, 
um damit die Ressourcen des Webserver nicht unnotig zu blockieren, 
[0045] Vorzugsweise umfaBt die Kennung die Lange des statischen Blocks. 

[0046] Zusatzlich zu jedem komprimierten Block wird vorzugsweise der dazu gehorige statische Block abgespeichert. 
Bei Bedarf steht dieser somit zur Verfugung. 60 
[0047] Die Daten werden vorzugsweise nach dem (an sich bekannten) DEFLATE- Verfahren komprimiert, Durch die 
Verwendung dieses bekannten Verfahrens ist eine Dekompression bei einem Empfanger bzw. Nutzer leicht moglich, 
[0048] Die dynamischen Blocke kann man im wesentlichen unverandert, insbesondere unkomprimiert im Datensatz 
senden. Wenn nun aber der Server zum Zeitpunkt, zu welchem die Webseite abgerufen wird, nur wenig ausgelastet ist, so 
kann man die dynamischen Blocke (oder einige der dynamischen Blocke) ebenfalls komprimieren und als komprimierte 65 
dynarnische Blocke in den Sendedatensatz einfugen. Es erfolgt also eine Komprimierung "on fly". Dadurch werden die 
vorhandenen Ressourcen optimal genutzt, eine "Dberlastung des Servers jedoch vermieden. 

[0049] Weiterhin besteht die Moglichkeit, dynarnische Blocke nicht nur unkomprimiert oder "on the fly" komprimiert 
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(je nach Serverlast) auszuliefern, sondern dynamische Blocke, welche durch ein bestimmtes Merkmal (z,B, ihrer GroBe) 
herausstechen, vorkomprimiert (wie die statischen Blocke) abzulegen. Dies wird im Fall des Merkmales der GroGe bei 
Uberschreiten eines Schwellwerts erfolgen. 

[0050] Weiterhin ist sinnvoll, fur jede Kompression eines Blockes eine erforderliche MindestgroBe (untere Schranke) 
5 zu definieren, welche uberschritten werden muB, damit eine Kompression iiberhaupt diirchgefuhrt wird. So konnen z. B. 
beim Server einer Zeitung Artikel aus einer Datenbank heraus generiert werden, die also dynamisch sind. Andererseits 
andert sich ein Artikel im Regelfall nicht mehr. Es macht also in diesem Fall Sinn, ihn hinsichtlich Kompression wie ei- 
nen statischen Block zu behandeln. 

[0051] Jedem letzten Block eines Datensatzes wird ein Endblock zur Bezeichnung des Endes des Datensatzes hinzu- 
10 gefugt, was die Handhabbarkeit der Datensatze erleichtert. 

[0052] Jedem Block des Datensatzes wird ein Tag zur Kennzeichnung als dynamischer oder als statischer Block hin- 
zugefugt, wobei diese Hinzufugung vorzugsweise an erster S telle des Blocks erfolgt Die lags werden vorzugsweise als 
HTML-Kommentar ausgebildet, 

[0053] Vorzugsweise werden die lags von einem Parser eingefiigt, der auf dem Application- Server lauft und auf abge- 
15 legte Templates zugreift, die er Block fur Block analysiert und denen er die Tags hinzufugt. Die mit den Tags markierte 
noch unkomprimierte Webseite wird einem Pre-Compressor zugeruhrt, der entsprechend markierte Blocke komprimiert, 
die zusammen mit unkomprirnierten Blocken dann einem Post-Compressor ubergeben werden. Der Post-Compressor er- 
stellt schritthaltend zur Datenbearbeitung durch den Pre-Compressor, also verzahnt mit diesem arbeitend ein neues Do- 
kument und zwar vorzugsweise nach dem GZip-Format. Nach Bildung eines GZip-Headers reiht der Post-Compressor 
20 die vom Pre-Compressor iibergebenen Blocke unmittelbar mit der Ubergabe in das neue Dokument ein, was eine hoch- 
effektive und schnelle Bearbeitung ermoglicht, 

[0054] Der Post-Compressor kennzeichnet unkomprimierte Blocke durch einen Header und zwar vorzugsweise einen 
solchen nach dem DEFLATE-FormaL 

[0055] Der Post-Compressor erstellt einen zusatzlichen END-Block und fiigt diesen zur Kennzeichnung eines Endes 
25 der Datenblocke dem neuen Dokument hinzu, Weiterhin errechnet der Post-Compressor eine Checksumme, insbeson- 
dere eine CR-32-Prufsumme und die GroBe des unkomprirnierten neuen Dokuments fur einen Trailer, der ebenfalls hin- 
zugerugt bzw. gesendet wird. 

[0056] Die erfindungsgemaBe Datenverarbeitungseinrichtung zum Komprimieren von dynamischen Webseiten, insbe- 
sondere zum Komprimieren von dynamischen Webseiten, die mindestens einen statischen Block und mindestens einen, 
30 insbesondere durch Abruf von einem Nutzer veranderlichen dynamischen Block aufweisen, unrtaBt einen Observer und 
einen Application-Server. Es ist ein Precompressor vorgesehen, der so ausgebildet ist, daB bei Aufforderung durch den 
Webserver an den Application-Server, eine dynamische Webseite zu generieren, der Precompressor eine noch unkompri- 
mierte Website in folgenden Schritten bearbeitet: 

Es wird festgestellt, ob statische Blocke mit derselben Identitat (mit demselben Fingerprint) in einem Blockspeicher 
35 schon als komprimierte Blocke gespeichert sind. Wenn dies der Fall ist, so wird der im Datensatz vorhandene statische 
Block durch den entsprechenden komprimierten Block ersetzt. Wenn dies nicht der Fall ist, so wird der statische Block 
komprimiert und im Blockspeicher als komprimierter Block abgelegt, Der komprimierte Block ersetzt dann wieder den 
im Datensatz vorhandenen statischen Block, 

[0057] AbschlieBend wird ein Sendedatensatz abgesendet, bei welchem die statischen Blocke durch komprimierte 
40 Blocke ersetzt sind, wobei der Sendedatensatz selbstverstandlich auch die dynamischen Blocke enthalt. 

[0058] Vorzugsweise wird die Identitat eines statischen Blocks anhand einer, aus ihm selbst gewonnenen Kennung 
festgestellt. Diese Kennung soli so sein, da!3 eine Verwechslung mit anderen statischen Blocken (Blocken anderen In- 
halts) unwahrscheinlich ist. Die aus der Identitat gewonnene Kennung wird jedem komprimierten Block zugehorig im 
Blockspeicher gespeichert und beim Feststellen der Identitat zum Vergleich mit den Identitaten der statischen Blocke im 
45 Datensatz verwendet. Es werden also nicht die statischen Blocke selbst miteinander verglichen sondem - was eine we- 
senuTche Verringerung des Aufwandes bedeutet - lediglich ihre Kennungen, Vorzugsweise wird als Kennung eine Priif- 
summe iiber den statischen Block, insbesondere eine CRC-32-Summe verwendet. 

[0059] Fiir SSC werden drei SSC-Komponenten in die bestehende Architektur auf der Serverseite eingefiigt - Pre-Pro- 
cessor, Pre-Compressor and Post-Compressor. Der Pre-Processor ist fest mit dem Application- Server verbunden, Pre- 
50 und Post-Compressor sind vom Application-Server unabhangig. 

[0060] Die drei SSC-Komponenten klinken sich in den Prozess der Erstellung bzw der Ubertragung einer dynami- 
schen Webseite ein. Sie werten jeden Block einer bereits generierten Seite aus, prufen, ob der Block statisch oder dyna- 
misch ist bzw, die Daten komprimiert oder unkomprimiert ubertragen werden sollen, und formatieren die Daten am Ende 
nach den GZip-Konventionen, 

55 [0061] Pre-Processor, Pre-Compressor und Post-Compressor sind die SSC-Komponenten, die in die serverseitige Ar- 
chitektur eingefiigt werden. Die Anordnung der SSC-Komponenten lasst sich durch den logischen DatenfluB vom Gene- 
rieren einer dynamischen Webseite verdeutlichen. 

[0062] Die Grafik gemaB Fig, 5 zeigt den logischen DatenfluB ohne die SSC-Komponenten, 

[0063] Der Webserver fordert den Application-Server auf, eine dynamische Webseite zu generieren. Der Parser analy- 
60 siert das Template der dynamischen Webseite auf seine statischen und dynamischen Blocke. Der Application-Server fugt 
dann die Inhalte der Blocke ein und iibergibt anschlieBend die fertige dynamische Webseite dem Webserver, 
[0064] Die Grafik gemaB Fig, 6 verdeutlicht den logischen DatenfluB mit SSC-Komponenten: 
Der Pre-Processor schlieBt sich unmittelbar dem Parser an bzw. verschmilzt mit diesem. Pre- und Post-Compressor - 
ebenfalls eng verknupft - bearbeiten die Daten nach dem Generieren durch den Apphcation-Server und ubergeben das 
65 S SC-Dokument dem Webserver. Pre- und Post-Compressor konnen - miissen aber nicht auf dem Applic ation-Server lau- 
fen. 

[0065] Den allgemeinen ProzeBablauf beschreibt der folgende Abschnitt. 

[0066] Der Webserver wertet den Request eines Nutzers aus. Hat dieser eine dynamische Webseite angefordert, leitet 
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er die Anfrage an den Application-Server weiter, Der Parser des Application-Server greift auf das abgelegte Tbmplate 
dleser Seite zu und analysiert es auf seine statischen und dynamischen Blocke. Gleichzeitig fugt der Pre-Processor an den 
Anfang von jedern Block ein entsprechendes SSC-Tag ein. Dieses SSC-Tag ist eine SSC-spezifische Markierung, die den 
Block fur SSC eindeutig als statisch bzw, dynamisch kennzeichnet. 

[0067] Danach generiert der Application-Server die Inhalte der Blocke, ohne die eingefugten SSC-Tags zu entfernen. 
Die fertige aber unkomprimierte dynamische Webseite iibergibt er dem Pre-Compressor. Dieser wertet die Webseite an- 
hand der SSC-Tags Block fur Block aus. Das bedeutet: 

- Er weist jedem Block eine Block-ID zu. Diese setzt sich aus der Lange des Blocks und einer errechneten Check- 
summe zusammen. Diese ermoglicht die eindeutige Erkennung des Blocks. 

- Soil der Block komprimiert werden, priift der Pre-Compressor anhand der Block-ED, ob es fur diesen Block be- 
reits eine Block-Datei gibt. Die Block-Datei enthalt den Inhalt eines Blocks kompriiniert und unkomprimiert Fin- 
det der Pre-Compressor die Block-Datei, ersetzt der Pre-Compressor den unkomprimierten Block der Webseite 
durch den komprirnierten Block aus der Block-Datei, Wenn nicht, komprimiert der Pre-Compressor den Block nach 
dem DEFLATE- Verfahren. Zusatzlich erstellt er eine Block-Datei und legt diese fur weitere Verwendungen ab. 

[0068] Parallel zum Pre-Compressor erstellt der Post-Compressor ein SSC-Dokument nach dem GZip Format, in das 
er die vom Pre-Compressor blockweise ubergebenen Inhalte einfugt. Das fertige SSC-Dokument wird uber den Webser- 
ver zum Browser des Nutzers iibertragen. 

[0069] Fig. 7 stellt die einzelnen Schritte beim Entstehen eines SSC-Dokuments aus dem Template der dynamischen 
Webseite dar, 

[0070] Jeder Block der dynamischen Webseite wird dem DEFLATE^ Verfahren unterzogen, D, h„ es komprimiert die 
Blocke zunachst nach festem und nach dynamischem Huffmann-Code und vergleicht die Ergebnisse mit dem Umfang 
der unkomprimierten Daten. Das Ergebnis mit dembesten Komprunierungsfaktor wird verwendet. Wird durch das Kom- 
primieren keine Verringerung des Datenumfangs erreicht, verarbeitet das DEFLATE- Verfahren die Daten unkompri- 
miert, 

[0071] Das DEFLATE- Verfahren fiigt jedem Block einen Header hinzu, deren Aufbau sich je nach verwendeten Daten 
unterscheidet. Die Header sind nachfolgend beschrieben. Der Endblock ist eine Besonderheit von SSC zum Kennzeich- 
nen des letzten Blocks. 

[0072] Das DEFLATE- Verfahren ist eine Kombination des LZ77 (Lempel-Ziv) Algorithmus und dem Kodieren nach 
Huffmann. Es ist in der Spezifikation RFC 1951 "DEFLATE Compressed Data Format Specification version L3" von Pe- 
ter Deutsch beschrieben und definiert 

[0073] Von dem Header eines komprirnierten Blocks sind die ersten drei Bits des ersten Byte wie folgt definiert: 
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Bit 7 6 5 4 3 

[0074] Die Bits bedeuten im einzelnen: 
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Flag, das nur beim letzten Block des SSC-Dokuments 
gesetzt wird. 
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10 


Spezifiziertdie nachfolgenden Daten: 
Unkomprimierte Daten 

Komprimierte Daten mit festen Huffmann-Code 
Komprimierte Daten mit dynamischen Huffmann-Code 
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Ersten Bits der komprirnierten Daten 
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[0075] Bei unkomprimierten Datenblocken sind die ersten funf Bytes definiert. Die ersten drei Bits von Byte 1 kenn- 
zeichnen einen Block als unkomprimiert. Daten bleiben unkomprirniert, wenn dies entsprechend konfiguriert wurde und/ 
oder wenn die Ergebnisse der zwei moglichen Kompressions verfahren (fester und dynanrischer Huffmann-Code) zu kei- 55 
ner Reduzierung des Datenumfangs fuhrt. Der Header setzt sich folgendermafien zusammen: 









1 




Byte 


2 3 


4 5 


0 


0 


0 


0 


0 


BTYPE 


BFINAL 


LEN 


NLEN 



Bit 7 6 5 4 3 2 

[0076] Die Bits von Byte 1 bedeuten im einzelnen: 



60 



65 
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Bit 


SSC- 
Wert 


Beschreibung 


0 

(BFINAL) 


0 


Flag, das nur beim letzten Block des SSC-Dokuments 
gesetzt wird. 


1-2 

(BTYPE) 


00 


Bitfolge fur unkomprimierte Daten 


3-7 


0 


Bits zum Auffullen des 1 . Bytes 



[0077] Bytes 2 und 3 beschreiben den Wert fiir die Lange des unkomprirnierten Blocks, Bytes 4 und 5 beschreiben den 
Wert fur die Lange des unkomprirnierten Blocks minus 1. 

[0078] Fiir den letzten Block innerhalb eines SSC-Dokuments muB nach der DEFLATE-Spezifikation das erste Bit 
15 (der BFTNAL-Hag) auf 1 gesetzt sein. 

[0079] Wahrend der blockweisen Bearbeitung der Daten ist es fur SSC nicht moglich, automatisch den letzten Block 
zu erkennen, Daher ist das BFINAL-Flag der Datenblocke immer 0, SSC fiigt am Ende einen zusatzlichen Block, den 
Endblock, ein und setzt das BFBNALrFlag auf 1. Dieser Endblock enthalt keine Daten, 

[0080] Der Pre-Processor ist eng mit dem Parser auf dem Application-Server verknupft und muB daher auch auf die- 
20 sem laufem 

[0081] Er markiert als ersten Schritt von SSC jeden Block einer dynamischen Webseite mit einem SSC-spezifischen 
Tag. Diese Tags sind Voraussetzung fur den weiteren SS C-Prozess, Der Pre-Processor kann nur templatebasierte dyna- 
mischen Webseiten bearbeiten. 

[0082] Die SSC-spezifischen Tags dienen dem Erkennen der Blocken einer dynamischen Webseite und dem Kenn- 
25 zeichnen dieser als statisch oder dynamisch. Der Pre-Processor fiigt sie an erste Stelle eines Blocks ein. 

[0083] Die zwei SSC-spezifischen Tags (statisch und dynamisch) entsprechen von ihrer Syntax her einem HTML 
Kommentar. Daraus ergibt sich der Vorteil, daB diese Tags als solche vom Application-Server erkannt aber nicht darge- 
stellt werden. Beispiele fur SSC-spezifische Tags sind: 

30 - statisch: < [--/©--> 

- dynamisch: <!--\@/--> 

[0084] Mit dem Abruf einer templatebasierten dynamischen Webseite greift der Parser des Application-Server auf das 
abgelegte Template zu, Der Parser analysiert das Template Block fiir Block auf deren Charakter (statisch oder dyna- 
35 misch). Gleichzeitig fiigt der Pre-Processor das entsprechende statische oder dynamische SSC-spezifische Tag an den 
Beginn des Blocks ein. Durch diesen parallelen Ablauf bleibt die benotigte zusatzliche Rechenlei stung gering. 
[0085] Fig, 8 zeigt beispielhaft das Einfugen der SSC-spezifischen Tags, <? ist das PHP-Anfangstag und ?> das Endtag 
fiir den dynamischen Block. 

[0086] Das so analysierte und markierte Template wird anschlieBend durch den Application-Server generiert. Die da- 
40 nach vollstandige unkomprimierte dynamische Webseite mit den eingefugten SSC-spezifischen Tkgs ubernimmt der Pre- 
Compressor. 

[0087] Der Pre-Compressor setzt eine mit SSC-spezifischen Tags vorbereitete dynamische Webseite voraus. Er iiber- 
nimmt diese mit generiertem Inhalt vom Application-Server. 
[0088] Er uberpruft fur jeden Block dieser Webseite: 

45 

- den Blocktyp (anhand des SSC-spezifischen Tag), 

- ob der Block komprimiert werden soli bzw. ob fur diesen Block bereits eine Block-Datei erstellt und abgelegt 
wurde. 

50 [0089] Zu komprimierende Blocke bearbeitet der Pre-Compressor nach dem DEFLAIT^Verfahren und iibergibt sie 
dem Post-Compressor. Blocke, die unkomprimiert bleiben, iibergibt er sofort dem Post-Compressor. 
[0090] Der Pre-Compres sor ist zusammen mit dem Post-Compressor unabhangig vom Application-Server. D . h. , beide 
konnen auch auf anderen Servereinheiten, z, B, dem Webserver, integriert sein, 

[0091] Der Pre-Compressor weist jedem zu komprimierendem Block eine eindeutige Block-ID zu, Diese Block-ID be- 
55 steht aus zwei Bestandteilen: der CRC-32 Prufsumme und der Lange des unkomprirnierten Blocks: 
Block-ID = <CRC-32><Lange des Blocks> 

[0092] Das Kreuzprodukt der CRC-32 Prufsurnme und der Lange des urikomprimierten Blocks ergibt eine Block-ID, 
mit der sich ein Block eindeutig bestimmen laBt und damit Vbrwechslungen mit hoher Wahrscheinlichkeit ausschlieBt. 
[0093] Fiir jeden Block einer dynamischen Webseite, der komprimiert werden soil, erstellt der Pre-Compressor eine 
60 Block-Datei. Diese Block-Datei ist in einem bestimmten Verzeichnis abgelegt (gecached) und besteht aus dem Block in 
unkomprimierter und in nach dem DEFLATE- Verfahren komprimierter Form. Der Name der Block-Datei wird von der 
Block-ED gepragt, die Endung kann dem Charakter des Blocks entsprechen. Beispiel fur eine Kennung ist: SSC-cache- 
<Lange>-<CRC-32>.static 

[0094] Fig, 9 zeigt den Aufbau einer Block-Datei. 
65 [0095] Der Pre-Compressor bearbeitet die vom Application- Server ubernommene dynamische Webseite blockweise. 
Dabei priift er als erstes, ob der Block komprimiert abgelegt werden soli oder nicht. Wenn nicht ubernimmt der Post- 
Compressor den unkomprirnierten Inhalt des Blocks, Ist eine Komprimierung gefordert, errechnet der Pre-Compressor 
fur den Block die Block-ID und priift mit dieser Block-ID, ob fur diesen Block bereits eine Block-Datei erstellt und ab- 
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gelegt ist. Entsprechend dem Ergebnis ergeben sich 2 Fallsituationen, 

Fall 1 (Fig. 10): Der Pre-Cornpressor findet die entsprechende Block-Datei. Der Post-Compressor ubernimmt den kom- 
primierten Block aus dieser Block-Datei. 

Fall 2 (Fig, 11): Es gibt noch kerne entsprechende Block-Datei, Der Pre-Compressor komprimiert den Block nach dem 
DEFLATE- Vertahren und ubergibt diesen den Post-Compressor. Zusatzlich erstellt er eine Block-Datei und legt diese ab, 5 
[0096] Der Post-Compressor ubernimmt vom Pre-Compressor die komprimierten bzw. unkomprimierten Blocke und 
erstellt aus diesen ein SSC-Dokument. 

[0097] Der Post-Compressor ist zusammen mit dem Pre-Compressor unabhangig vom Application-Server. D, h, 3 beide 
konnen auch in anderen Servereinheiten, z, B, dem Webserver, integriert sein, 

[0098] Das SSC-Dokument setzt sich, wie aus Fig, 12 erkennbar, aus einem Header, den einzelnen Datenblocken und 10 
einem Trailer zusammen. Dieser Aufbau entspricht dem GZip-Format, der in der Spezifikation RFC 1952 "GZEP file for- 
mal specification version 43" von Peter Deutsch definiert und beschrieben ist. 

[0099] Der Aufbau des Header (Kopf) vom SSC-Dokument setzt sich folgendermaBen zusammen: 



1 


2 


3 


4 


5 6 7 


6 


9 


10 


ID1 


ID2 


CM 


FLG 


MTIME 


XFL 


OS 



[0100] Die einzelnen Bytes bedeuten: 20 



Byte 


SSC-Wert 


Beschreibung 


1 




ID1 - erstes Byte zur Identifizierung des gzib-Formats 


2 


8B H ex 


ID2 - zweites Byte zur Identifizierung des gzib-Formats 


3 


8 


CM - Byte bestimmt Komprimierungsmethode (deflate) 


4 


0 


FLG - Einstellungen 


5-8 


0 


MIME - Zeit der Komprimierung der Datei fur SSC alle 4 
Bytes 0 -» kein Zeitstempel 


9 


0 


XFL - Flag fur spezifische Komprimierungsmethoden 


10 


0 


OS - Byte zur Identifizierung des Betriebssytems 



[0101] Das SSC-Dokument endet mit einem 8 Byte groBern Trailer (Anhang). Diese Bytes haben folgende Bedeutung: 



Byte 


Beschreibung 


1 -4 


CRC32 - Checksumme 


5-8 


ISI2E - GroBe des unkomprimierten Datenblocks 



[0102] Der Post-Compiessor erstellt parallel zur Auswertung der dynamischen Webseite durch den Pre-Compressor 
ein neues Dokument nach dem GZip-Format, Dabei bildet der Post- Compressor zunachst den GZip- Header. Anschlie- 
Bend reiht er unmittelbar mit der Ubergabe der Blocke durch den Pre-Compressor diese Block fur Block in das Doku- 
ment ein. 

[0103] Unkomprimierte Blocke, die der Pre-Compressor ohne Bearbeitung weiterleitet, kennzeichnet der Post-Corn- 45 
pressor durch einen Header entsprechend dem DEFIATE-Format, 

[0104] Sind alle Blocke der dynamischen Webseite abgearbeitet, erganzt der Post-Compressor einen zusatzlichen End- 
Block, der keine Daten enthalL Das BFINAL-Hag (BFINAL = 1) im Header des End-Blocks kennzeichnet das Ende der 
Datenblocke, 

[0105] Als letzten S chiitt errechnet der Post-Compies sor die Checksumme und die Grol3e des unkomprimierten Daten- 50 
blocks fur den Trailer. 

[0106] Das fertige SSC-Dokument ubergibt der Post-Compressor dem Webserver, der dieses zum Nutzer weiterleitet. 
[0107] In der beiliegenden Fig. 1 3 ist ein Ausfuhrungsbeispiel der erfindungsgemaBen Datenverarbeitungseinrichtung 
im Prinzip gezeigt. Hierbei ist ein Webserver 10 mit einem Application-Server 11 verbunden, auf welchem ein Parser 12 
lauft. Der Parser 12 ist eng mit einem Pre-Processor verbunden, lauft also ebenfalls auf dem Application-Server 11. Der 55 
Pre-Processor (mit dem Parser) bearbeitet die dynamischen, templatebasierten Webseiten* 

[0108] Es ist ein Pre-Compressor 14 vorgesehen, der zusammen mit einem Post- Compressor 15 vorzugsweise unab- 
hangig vom Application-Server ist, also mit dem Pre-Compressor 14 z, B. im Webserver integriert sein kann. Schliefilich 
ist ein Blockspeicher 13 vorgesehen, der mit dem Pre-Compressor 14 verbunden ist, so daB der Pre-Compressor 14 den 
Blockspeicher 13 auf dort schon gespeicherte komprimierte statische Blocke untersuchen bzw. statische Blocke nach 60 
dem Komprimieien dort ablegen kann. 



Bezugszeichenliste 

10 Webserver 65 

11 Application-Server 

12 Parser 

13 Blockspeicher 
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14 Pre-Compressor 

15 Post-Compressor 

Patentanspriiche 

5 

L Verfahren zuin Komprimieren von dynamischen Webseiten, insbesondere zum Kompriinieren von Webseiten, 
die mindestens einen statischen Block und wenigstens einen dynamischen, insbesondere durch Abruf von einem 
Nutzer verariderlichen Block aufweisen, die auf einem Webserver und einem Application- Server vorgehalten oder 
generiert werden, umfassend die Schritte: 
10 - Aufnehmen eines Datensatzes, umfassend mindestens einen statischen und einen dynamischen Block; 

- Feststellen jeweils einer Identitat aller im Datensatz vorhandenen statischen Blocke; 

- Feststellen, ob statische Blocke mit derselben Identitat in einem Blockspeicher schon als komprimierte 
Blocke gespeichert sind und 

- entweder Ersetzen des im Datensatz vorhandenen statischen Blocks durch einen komprimierten Block 
15 dann, wenn der statische Block im Blockspeicher als komprimierter Block gespeichert ist; 

- oder Komprimieren des statischen Blocks und Abspeichern im Blockspeicher als komprimierter Block 
dann, wenn der statische Block noch nicht im Blockspeicher gespeichert ist und Ersetzen des statischen 
Blocks durch den komprimierten Block; 

- Absenden eines Sende-Datensatzes, bei welchem die statischen Blocke durch komprimierte Blocke ersetzt 
20 sind und der die dynamischen Blocke enthalt. 

2, Verfahren nach Anspruch 1, wobei die Identitat eines statischen Blocks anhand einer, aus ihm selbst gewonnenen 
Kennung (Fingerprint) festgestellt wird, 

3. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 2, wobei die aus der Identi- 
tat gewonnene Kennung jedem komprimierten Block zugehorig im Blockspeicher gespeichert und beim Feststellen 

25 der Identitat zum Vergleich mit den Identitaten der statischen Blocke im Datensatz verwendet wird. 

4, Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 2 oder 3, da- 
durch gekennzeichnet, daB die Kennung eine Prufsumme iiber den statischen Block urnfaBt. 

5. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 4, dadurch gekennzeichnet, 
daB die Kennung die Lange des statischen Blocks umfaBt 

30 6, Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB zusatzlich zu jedem kom- 

primierten Block der dazugehorige statische Block abgespeichert wird. 

7. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Daten nach dem DE- 
FLATE- Verfahren komprimiert werden. 

8. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die dynamischen Blocke im 
35 wesentlichen unverandert, insbesondere unkomprimiert im Sende-Datensatz enthalten sind. 

9. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 1 bis 7, dadurch 
gekennzeichnet, daB mindestens ein dynamischer Block komprimiert und als komprimierter dynamischer Block in 
den Sende-Datensatz eingefiigt wird. 

10. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 9, dadurch gekennzeich- 
40 net, daB abhangig von einer momentanen Arbeitsbelastung eines Servers, insbesondere des Webservers, dynami- 

sche Blocke komprimiert oder unkomprimiert abgesendet werden, 

11. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB jedem letzten Block eines 
Datensatzes ein Endblock zur Bezeichnung des Endes des Datensatzes hinzugefiigt wird. 

12. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB jeder Block des Datensat- 
45 zes ein Tag zur Kennzeichnung als dynamischer oder als statischer Block insbesondere an erster S telle hinzugefiigt 

wird. 

13. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 12, dadurch gekennzeich- 
net, daB die Tags als HTML-Kommentar ausgebildet sind. 

14. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 12 oder 13, da- 
50 durch gekennzeichnet, daB die Tags von einem Parser eingefiigt werden, der auf einem Application-Server lauft und 

auf abgelegte Templates zugreift, die er Block fur Block analysiert und denen er die Tags hinzutugt. 

15. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 14, dadurch gekennzeich- 
net, daB die mit den Tags markierte unkomprimierte Webseite einem Prekompressor zugefuhrt wind, der entspre- 
chend markierte Blocke komprimiert, die zusammen mit unkomprimierten Blocken einem Postkompressor iiberge- 

55 ben werden. 

16. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 15, dadurch gekennzeich- 
net, daB der Postkompressor schritthaltend zur Datenbearbeitung durch den Prekompressor ein neues Dokument, 
vorzugsweise nach dem Gzip-Format erstellt 

17. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 16, dadurch gekennzeich- 
60 net, daB der Postkompressor nach Bildung eines Gzip-Headers die vom Prekompressor ubergebenen Blocke unmit- 

telbar mit der Ubergabe in das neue Dokument einreiht. 

18. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 17, dadurch gekennzeich- 
net, daB der Postkompressor unkomprimierte Blocke durch einen Header, vorzugsweise einen Header entsprechend 
dem DEFLATE-Format kennzeichnet. 

65 19. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 15 bis 18, da- 

durch gekennzeichnet, daB der Postkompressor einen zusatzhchen END-Block erstellt und zur Kennzeichnung ei- 
nes Endes der Datenblocke dem neuen Dokument hinzufugt. 

20. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 16 bis 19, da- 
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durch gekennzeichnet, daB der Postkompressor eine Checksumme, insbesondere eine CR-3 2-Pruf summe und die 
GroBe des unkomprirrderten neuen Dokuments fur einen Trailer errechneL 

2L Verfahren nach einem der vorhcrgehenden Anspriiche, insbesondere nach Anspruch 9, dadurch gekennzeich- 
net, daB dynamische Blocke in Abhangigkeit 

von mindestens einem ihnen innewohnenden Merkmal, insbesondere in Abhangigkeit von ihrer GroBe vorkompri- 5 
miert gespeichert werdem 

22. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, da!3 

eine Kompression von Datenblocken nur dann vorgenommen wind, wenn diese eine voreinstellbare MindestgroBe 
uberschreiten. 

23. Datenverarbeitungseinrichtung zum Komprimieren von dynamischen Webseiten, insbesondere zum Kompri- 10 
mieren von dynamischen Webseiten, die mindestens einen statischen Block und mindestens einen dynamischen 
Block aufweisen, umfassend 

einen Webserver (10) und einen Application-Server (11), gekennzeichnet durch einen Prekompressor, der so ausge- 
bildet ist, da!3 bei Aufforderung durch den Webserver (10) an den Application-Server (11) eine dynamische Web- 
seite zu generieren, der Prekompressor eine unkomprimierte Webseite in folgenden Schritten bearbeite: 15 

- Feststellen jeweils einer Identitat aller im Datensatz vorhandenen statischen Blocke; 

- Feststellen, ob statische Blocke nrit derselben Identitat in einem Blockspeicher schon als komprimierte 
Blocke gespeichert sind und 

- entweder Ersetzen des im Datensatz vorhandenen statischen Blocks durch einen komprimierten Block 
dann, wenn der statische Block im Blockspeicher als komprimierter Block gespeichert ist; 20 

- oder Komprimieren des statischen Blocks und Abspeichem im Blockspeicher als komprimierter Block 
dann, wenn der statische Block noch nicht im Blockspeicher gespeichert ist und Ersetzen des statischen 
Blocks durch den komprimierten Block; 

- Absenden eines Sende-Datensatzes, bei welchem die statischen Blocke durch komprimierte Blocke ersetzt 
sind und der die dynamischen Blocke enthalt, 25 

24. Datenverarbeitmgseinrichtung nach Anspruch 23, dadurch gekennzeichnet, daB der Parser (12) so ausgebildet 
ist, daB die aus der Identitat gewonnene Kennung jedem komprimierten Block zugehorig im Blockspeicher gespei- 
chert und beim Feststellen der Identitat zum Vergleich mit den Identitaten der statischen Blocke im Datensatz ver- 
wendet wird. 

25. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 oder 24, dadurch gekennzeichnet, daB der Web- 30 
server (10) derart ausgebildet ist, daB abhangig von seiner momentanen Arbeitsbelastung dynamische Blocke kom- 
primiert oder unkomprimiert abgesendet werden. 

26. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 25, dadurch gekennzeichnet, daB der Parser 
(12) derart ausgebildet ist, daB Tags von ihm eingefiigt werden, wobei der Parser (12) auf dem Application-Server 
(11) lauft und auf abgelegte Templates zugreift, die er Block fur Block analysiert und denen er die Tags hinzufugt. 35 

27. Datenverarbeitmgseinrichtung nach einem der Anspriiche 23 bis 26, dadurch gekennzeichnet, daB ein Prekom- 
pressor (14) vorgesehen ist, welchem die mit den Tags markierten unkomprimierten Webseiten zugefuhrt werden 
und der zu Komprimierung entsprechend markierter Blocke ausgebildet ist, und daB ein Postkompressor (15) vor- 
gesehen ist, dem die komprimierten Blocke zusammen mit unkomprimierten Blocke vom Prekompressor (14) iiber- 
geben werden. 40 

28. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 27, dadurch gekennzeichnet, daB der Post- 
kompressor (15) schritthaltend zurDatenverarbeitung durch den Prekompressor (14) und zurErstellung eines neuen 
Dokuments vorzugsweise nach dem Gzip-Format ausgebildet ist. 

29. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 28, dadurch gekennzeichnet, daB der Post- 
kompressor (15) zur Bildung eines Gzip- Headers und zur unmittelbaren Einreihung der vom Prekompressor (14) 45 
ubergebenen Blocke mit der tlbergabe in das neue Dokument ausgebildet ist. 

30. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 29, dadurch gekennzeichnet, daB der Post- 
kompressor (15) zur Kennzeichnung unkomprimierter Blocke durch einen Header, vorzugsweise einen Header ent- 
sprechend dem DEFLATE-Format ausgebildet ist. 

31. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 30, dadurch gekennzeichnet, daB der Post- 50 
kompressor (15) zur Erstellung eines zusatzlichen END-Blocks und zur Hinzufugung des END-B locks zur Kenn- 
zeichnung eines Endes der Datenblocke zum neuen Dokument ausgebildet ist. 

32. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 31, dadurch gekennzeichnet, daB der Post- 
kompressor (15) zur Bildung einer Checksumtne und Herleitung der GroBe des unkomprimierten neuen Dokuments 
und zur Erstellung eines Trailers ausgebildet ist. 55 

33. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 32, dadurch gekennzeichnet, daB der Prekom- 
pressor derart ausgebildet ist, daB dynamische Blocke in Abhangigkeit von mindestens einem ihnen innewohnen- 
den Merkmal, insbesondere in Abhangigkeit von ihrer GroBe vorkompri miert gespeichert werden, 

34. Datenverarbeitungseinrichtung nach einem der Anspriiche 23 bis 33, dadurch gekennzeichnet, daB der Prekom- 
pressor derart ausgebildet ist, daB eine Kompression von Datenblocken nur dann vorgenommen wird, wenn diese 60 
eine voreinstellbare MindestgroBe uberschreiten. 
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